


中 华人 民 共 和 国 国 家 标准 


GB/T 15532—1995 


计算 机 软件 单元 测试 


Computer software unit testing 


1995- 04- 05 发 布 1995- 12- 01 实施 


中 华人 民 共 和 国 国 家 标准 


GB/T 15532 一 1995 


计算 机 软件 单元 测试 


Computer software unit testing 


1 主题 内 容 与 适用 范围 


1.1 主题 内 容 
软件 单元 测试 是 一 个 过 程 。 本 标准 为 该 过 程 规 定 了 一 个 标准 的 方法 ,使 之 成 为 软件 工程 实践 中 的 基 
础 。 该 方法 是 一 种 综合 的 方法 ,目的 是 对 软件 单元 进行 系统 化 的 测试 ,包括 测试 计划 的 执行 ,测试 集 的 获 
取 以 及 测试 单元 与 其 需求 的 对 照 衡量 ,对 照 衡量 包括 使 用 样本 数据 来 执行 被 测 单元 ,并 将 该 单元 的 实际 
结果 与 单元 的 需求 文件 中 指定 的 结果 进行 比较 。 
本 标准 描述 了 一 个 测试 过 程 , 它 由 一 系列 具有 层次 结构 的 阶段 ,活动 及 任务 组 成 , 且 为 每 一 活动 定 
义 了 一 个 最 小 任务 集 。 
1.2 适用 范围 
本 标准 可 适用 于 任何 计算 机 软件 的 单元 测试 (包括 新 开发 的 或 修改 过 的 软件 单元 ) 。 本 标准 并 不 规 
定 这 些 软件 的 类 型 ,也 不 规定 哪些 软件 必须 进行 单元 测试 。 
本 标准 不 涉及 其 他 综合 性 的 单元 验证 或 确认 过 程 , 象 评审 (例如 走 查 .审查 ) .静态 分 析 ( 例 如 一 致 性 
核查 \ 数 据 流 分 析 ) 或 形式 化 分 析 ( 例 如 正确 性 证 明 、 符 号 执行 )。 
本 标准 不 要 求 使 用 特定 的 测试 机 制 或 工具 。 本 标准 也 不 强 含 任何 特定 的 方法 学 以 进行 文件 控制 , 配 
置 管理 ,质量 保证 ,或 测试 步骤 管理 。 同 时 也 不 规定 软件 排 错 的 过 程 。 
本 标准 的 使 用 者 可 以 是 测试 人 员 , 也 可 是 开发 人 员 。 


2 引用 标准 


GB 9386 计算 机 软件 测试 文件 编制 规范 
GB/T 11457 软件 工程 术语 
GB/T 12505 计算 机 软件 配置 管理 计划 规范 






























































































































































































































































































































































































































































3 术语 
下 列 术 语 定 义 适用 于 本 标准 ,其 他 术语 见 GB 9386 和 GB/T 11457。 
3. 1 特性 characteristic 
见 数据 特性 (3.2 条 ) 或 软件 特性 (3.5 条 )。 
3.2 数据 特性 ”data characteristic 
数据 的 一 种 固有 的 (也 可 能 是 非 固 有 的 ) 性 质 \ 质 量 或 特征 (例如 数据 使 用 率 \ 格 式 \、 值 范围 或 域 值 间 
关系 )。 
3. 5 ” 非 过 程 性 编程 语言 monprocedure ptogtamming language 
与 过 程 性 编程 语言 相对 。 是 一 种 用 于 表达 问题 的 参数 ,而 不 是 表达 解决 问题 的 步骤 的 计算 机 编程 语 
言 ( 例 如 :报告 生成 器 或 分 类 的 规范 化 语言 )。 
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3. 4 过 程 性 编程 语言 “ptocedute programming language 
与 非 过 程 性 编程 语言 相对 。 是 一 种 用 于 表达 操作 步骤 ,以 供 计算 机 执行 的 编程 语言 (例如 
COBOL), 
3.5 软件 特性 ”software characteristic 
软件 的 一 种 固有 的 (也 可 能 是 非 固 有 的 ) 性 质 \ 质 量 或 特征 (例如 功能 ,性 能 、 属 性 、 设 计 约 束 、 状 态 数 
目 ,分 支 的 行 数 等 )。 
3.6 软件 特征 softwatre feature 
需求 文件 所 规定 或 缠 含 的 软件 特性 (例如 ;功能 ,性 能 ,属性 或 设计 约束 )。 
3.7 软件 测试 事件 software test incident 
在 软件 测试 期 间 所 发 生 的 任何 事件 。 
3.8 状态 数据 state date 
确定 测试 单元 内 部 状态 的 数据 , 它 用 于 建立 状态 或 与 现存 状态 比较 。 
3.9 测试 对 象 test objective 
在 指定 条 件 下 ,通过 对 软件 的 实际 状况 与 软件 文件 9 
3. 10 ”测试 集结 构 test set architecture 
测试 用 例 集 ( 测 试 集 ) 的 蔡 套 关系 , 它 能 直接 反映 测试 对 象 的 层次 分 解 情 况 。 
3. 11 测试 单元 test unit 
一 个 包括 一 个 或 多 个 计算 机 程序 模块 及 相应 控制 数据 (例如 表格 )、 调 用 过 程 \ 操 作 过 程 的 模块 集 
合 , 且 该 集合 成 员 满 足下 列 条 件 ， 
所 有 模块 属于 同一 个 计算 机 程序 系统 ; 
故 合 中 至 少 有 一 个 模块 (新 的 或 改变 过 的 模块 7) 尚未 完成 单元 测试 ; 
所 有 模块 及 相应 数据 和 过 程 的 集合 是 一 个 测试 过 程 的 唯一 对 象 。 
注 : @@ 一 个 测试 单元 可 能 出 现在 从 一 个 单独 的 模块 到 一 个 完整 的 程序 这 样 一 种 设计 层次 的 任何 一 个 级 别 中 。 因 
此 一 个 测试 单元 可 能 是 一 个 模块 一 些 模 块 ,或 一 个 具有 相关 数据 和 过 程 的 完整 的 计算 机 程序 。 
@ 一 个 测试 单元 可 能 包含 一 个 或 多 个 已 进行 过 单元 测试 的 模块 。 
3. 12 单元 unit 
见 测试 单元 。 
3. 15 单元 需求 文件 unit requirement documentation 


论述 被 测 单元 的 功能 需求 ,接口 需求 ,性 能 需求 及 设计 约束 需求 的 文件 。 
4 单元 测试 活动 
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本 章 规定 单元 测试 过 程 所 涉及 的 活动 ,每 个 活动 按 输 入 、 任 务 和 输出 这 样 的 结构 加 以 
的 阶段 及 活动 如 下 ， 

a. ”完善 测试 计划 ， 
制定 方法 ,资源 及 进度 的 计划 
一 一 确定 需 测 试 的 与 需求 有 关 的 特性 ; 
一 一 细 化 计划 。 
b- 获得 测试 集 ， 
一 一 设计 测试 集 ; 
一 一 执行 计划 及 实现 设计 。 
ce. 评价 测试 单元 ， 
一 一 执行 测试 规程 ; 
一 一 核对 终止 情况 ; 
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一 一 评价 测试 效果 和 测试 单元 。 
所 有 活动 的 流程 见 图 1。 
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评价 


图 1 单元 测试 活动 流程 











当 一 个 以 上 的 单元 需 进 行 单元 测试 时 (例如 所 有 的 这 些 单元 均 与 一 个 软件 项 目 有 关 ), 则 计划 活动 
须 指出 每 个 单元 在 整个 测试 单元 集合 中 的 位 置 , 以 免 在 每 个 测试 单元 中 重复 。 
在 一 般 情 况 下 ,除了 图 1 中 执行 测试 规程 和 核对 结果 这 两 个 循环 活动 外 ,所 有 活动 必须 顺序 进行 。 
对 于 除 制 订 计 划 阶 段 外 的 任何 一 个 活动 , 若 其 前 面 的 活动 或 某 一 外 部 事件 (例如 进度 需求. 设计 2 有 银 
则 有 必要 重新 执行 其 前 面 的 若干 个 活动 ,然后 返回 到 当前 活动 。 
各 阶段 的 输入 、 输 出 数据 流 见 图 2。 
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项 目 信息 
完善 测试 
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-一 一 [( 获得 测试 集 
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图 2 软件 单元 测试 各 阶段 的 主要 数据 流 
在 每 个 阶段 ,每 个 基本 活动 都 连 有 其 自身 的 输入 集 和 输出 集 , 其 内 容 由 一 系列 任务 组 成 。 本 标准 描 
















































































3 


GB/T 15532 一 1995 







































































述 了 每 个 活动 的 输入 、 任 务 、 输 出 。 所 有 活动 的 输出 集 应 当 包 含 足够 的 信息 来 创建 至 少 以 下 两 个 文件 ;一 
份 测试 设计 说 明 及 一 份 测试 总 结 报告 。 所 有 文件 必须 符合 GB 9386 中 的 规定 。 所 有 的 测试 文件 必须 标 
明 作 者 及 日 期 。 

测试 设计 说 明 将 从 确定 测试 特性 、 细 化 计划 及 设计 测试 集 这 儿 个 活动 中 获得 信息 ;测试 总 结 报告 将 








从 所 有 的 活动 中 获得 信息 。 
4.1 制订 方法 ,资源 及 进度 的 计划 





总 的 单元 测试 计划 应 当 在 综合 测试 计划 


4.1.1 输入 
a. 项 目 计划 
b. 软件 需求 文件 。 
4. 1.2 任务 
a. 指定 单元 测试 的 总 方法 
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必须 使 用 




















技术 。 确 定 用 于 记录 ,收集 、 化 简 和 下 


















































件 的 准备 情况 。 
b. 指定 完备 的 测试 要 






































确定 站 





域 所 要 求 的 覆盖 程度 。 








在 软件 开发 期 间 进行 上 
准 。 此 原则 也 适用 于 软件 维护 时 的 单元 测试 。 
当 在 软件 开发 期 间 测 试 一 个 用 过 程 性 语言 ( 例 





















































确定 测试 欲 发 现 的 风险 区 域 。 指 
































元 测试 集 所 歼 盖 的 区 域 ( 例 如 软件 特 生 


元 测试 时 ,每 一 软 从 

















定 对 确定 特性 ( 
的 测试 集 ) 等 这 几 个 活动 阶段 的 限制 。 

确定 现 有 的 输入 、 输 出 和 数据 资源 (例如 测试 文件 ,制作 文件 .测试 数据 生成 器 )， 确定 数据 确认 的 总 
认输 出 数据 的 总 技术 。 描 述 与 被 测试 的 单元 有 直接 接口 的 应 用 软 



































期 间 制 订 , 且 应 在 相应 的 计划 文件 中 作出 记录 。 





刚 如 需 测试 的 特性 ) ,设计 测试 集 或 实现 测试 (例如 






























































EE、 过程 ,状态 、 功 能 ,数据 特性 ,指令 等 ) 以 及 对 每 一 区 








F 特 征 必 须 至 少 被 一 测试 用 例 所 鹤 盖 ,例外 情况 须 得 以 批 





如 COBOL) 实 现 的 单元 时 ,对 每 一 指令 (能 够 到 达 


及 执行 的 ), 除 非 该 指令 所 在 的 模块 已 经 独立 地 进行 过 单元 测试 ,或 者 得 到 茶 种 特许 , 它 必 须 被 某 一 测试 
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指定 











j 例 所 履 盖 。 此 原则 也 适用 于 软件 给 
指定 终止 测试 的 要 求 
单元 测试 过 程 正 常 终止 的 需求 。 终 目 需 求 必 须 满足 需求 完备 性 。 
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d. 


估计 进行 讽 





应 的 通告 过 程 。 
决定 资源 的 要 求 


























1 试 集 获 取 、 初 始 启 动 及 后 


E 护 时 






































(例如 所 用 的 计算 机 时 间 )、 通 信 或 系统 软件 ,测试 工具 ,测试 文件 等 。 
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e. 
指定 
4. 1.5 
a. 
b. 





指定 总 的 进度 安排 



























































4.2 确定 需 测试 的 与 需求 有 关 的 特性 

















4.2.1 


Aa. 


输入 


单元 需求 文件 ; 











用 过 程 性 语言 实现 的 软件 的 单元 测试 。 











确定 会 导致 单元 测试 过 程 异 常 终止 的 任何 情况 (例如 发 现 主要 的 设计 缺陷 ,到 达 的 最 终 期 限 ) 以 及 








续 测试 活动 反复 执行 所 需 的 资源 。 应 考虑 硬件 情况 ,访问 时 间 

















资源 和 测试 单元 所 决定 的 单元 测试 活动 的 进度 。 
输出 
单元 测试 计划 (从 4.1.2 条 的 a~e 得 到 )， 


单元 测试 的 总 体 资源 请 求 ( 若 能 从 4 1.2 条 的 d 得 到 )。 








确定 需要 准备 的 以 及 各 部 门 响应 所 需 的 资源 ,包括 那些 对 于 其 交付 时 间 有 严格 要 求 的 资源 (例如 定 
制 的 测试 工具 ,并 安排 这 些 资源 。 
有 定 对 单元 测试 及 单元 排 错 负责 的 部 门人 员 技 能 ,数量 及 可 参加 时 间 的 要 求 。 
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b. 软件 结构 设计 的 文件 ( 若 需 要 ) 。 
4.2.2 任务 

a. ”研究 功能 需求 

研究 单元 需求 文件 中 描述 的 每 一 功能 。 保证 每 一 功能 有 唯一 的 标识 符 。 若 需要 的 话 ,应 对 需求 进行 
分 类 。 

b. 定 附加 需求 及 相应 规程 

对 于 那些 没有 被 需求 指定 , 却 在 单元 测试 一 级 有 效 测试 的 软件 特性 (例如 软件 性 能 ,属性 或 设计 约 
束 ) ,确定 与 之 相关 的 需求 语句 ,使 之 成 为 附加 需求 。 确 定 那 些 仪 与 待 测试 单元 有 关 的 使 用 或 操作 规程 。 
外 保 每 一 附加 需求 及 规程 有 唯一 的 标识 符 。 若 需要 的 话 , 应 对 需求 进行 分 类 。 

ec. 确定 单元 状态 

车 单元 需求 文件 指定 或 缠 含 了 多 种 状态 《例如 不 活动 ,等待 接 收 、 处 理 ) 软 件 , 则 确定 每 一 状态 及 每 
一 有 效 状态 转换 。 保 证 每 一 状态 及 状态 转换 有 唯一 标识 符 , 若 需要 的 话 , 应 对 需求 进行 分 类 。 

d. ”确定 输入 及 输出 数据 特性 

确定 待 测 试 单 元 的 输入 及 输出 数据 结构 。 对 每 一 结构 ,确定 其 特性 ,诸如 使 用 率 、 格 式 、 值 范围 和 域 
值 之 间 的 关系 。 对 每 个 特性 ,指定 其 有 效 范 围 。 保 证 每 一 特性 有 唯一 标识 符 。 若 需要 的 话 ,应 对 需求 进 


行 分 类 。 
€. 
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选择 包含 于 测试 中 的 各 要 素 
选择 待 测试 的 软件 特征 。 选 择 其 相应 规程 ,状态 及 状态 转换 ,以 及 测试 时 的 有 关 数 据 特性 。 无 效 及 
有 效 数 据 都 应 选择 。 当 无 法 进行 这 种 完整 的 测试 时 , 则 应 该 利用 如 何 使 用 该 单元 的 信息 决定 选择 的 内 
容 。 对 于 不 能 选择 的 要 素 , 确 定 由 此 可 能 带 来 的 风险 问题 。 
将 所 选 的 特性 ,规程 ,状态 ,状态 转换 及 数据 特性 等 数据 记录 在 单元 测试 设计 说 明 中 的 “被 测试 的 特 
性 ”一 章 中 ( 见 GB 9386) 。 
4.2.5 输出 
a. ”测试 过 程 中 包含 的 各 要 素 的 列表 (从 4.2.2 条 的 e 得 到 7; 
b- 单元 需求 分 类 的 信息 ( 若 能 从 4.2.2 条 的 a~d 得 到 )。 
4.35 细 化 计划 
4.5.1 输入 
a. ”测试 过 程 中 包含 的 各 要 素 的 列表 (从 4.2.2 条 的 e 得 到 78 
b. 单元 测试 计划 (从 4.1.2 条 的 a~e 得 到 )。 

































































































































































4.3.2 任务 
a. 方法 




































































确定 可 以 考虑 利用 的 现 有 的 测试 用 例 及 测试 规程 。 确 定 用 于 数据 确认 的 任何 特定 技术 。 确 定 用 了 
输出 记录 、 输 出 收集 ,输出 化 简 及 输出 确认 所 用 的 技术 。 将 细 化 的 方法 记录 于 单元 的 测试 设计 说 明文 件 
中 的 “方法 详 述 ” 一 章 中 ( 见 GB 9386) 。 

b. 详 述 指定 的 资源 需求 
定 所 指定 的 测试 单元 所 需 的 资源 (例如 与 该 单元 直接 接口 的 软件 )。 并 为 已 确定 的 资源 作 准 备 。 将 
指定 资源 的 需求 记录 在 单元 测试 设计 说 明 的 "方法 详 述 ” 一 章 中 。 
. 指定 详细 进度 
R 据 支撑 软件 、 指 定 资源 .所 使 用 单元 的 可 获得 性 及 组 装 进度 ,为 单元 测试 规定 相应 进度 将 该 进度 
记录 于 单元 的 测试 设计 说 明 的 “方法 详 述 ” 一 章 中 。 
4.35.35 输出 

a. 详细 的 单元 测试 计划 (从 4. 3.2 条 的 a~e 得 到 ); 

b. 单元 测试 的 指定 资源 要 求 ( 若 能 从 4. 3.2 条 的 b 得 到 )。 
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4. 4 设计 测试 
4.4.1 输入 








7 


















































a. ”单元 需求 文件 ; 
b. 测试 过 程 中 所 包含 的 各 要 素 的 列表 (从 4.2.2 条 的 e 得 到 7; 
ec. ”单元 测试 计划 (从 4.1.2 条 的 a 和 b 及 4.3.2 条 的 a 得到)，; 
d. 单元 设计 文件 ; 
e. 来 自 以 前 测试 的 测试 规格 说 明 ( 若 可 获得 的 话 )。 

4.4.2 任务 





a. 设计 测试 集 的 层次 结构 

根据 待 测 试 的 软件 特征 和 由 所 选 的 有 关 要 素 ( 例 如 规程 ,状态 转换 .数据 特 性 ) 所 指定 或 蔓 含 的 情 
况 ， 设 计 一 个 按 层次 分 解 好 的 测试 对 象 集 , 使 得 最 低层 的 每 一 对 象 能 直接 用 一 些 测 试用 侈 进行 测试 。 选 
择 合 适 的 现 有 的 测试 用 例 ,将 测试 用 例 标 识 符 组 与 最 低层 的 相应 的 对 象 相关 联 。 将 对 象 层次 和 相应 的 测 
试用 例 标 识 符 记 录 于 单元 的 测试 设计 说 明 中 的 “测试 用 例 名 称 ” 一 章 中 ( 见 GB 9386) 。 

b. 按 需 求 获 得 清晰 的 测试 规程 

单元 需求 文件 .单元 测试 计划 及 测试 用 例 说 明 的 组 合 可 能 会 隐 含 地 指定 出 单元 测试 规程 ,从 而 不 需 
要 更 细致 的 “测试 规程 说 明 ”。 选 择 现存 的 测试 规程 , 稍 作 修改 或 不 加 修改 地 使 用 。 

车 单元 测试 设计 说 明 的 补充 章 条 有 要 求 ,或 另外 的 规程 说 明文 件 有 要 求 ,应 指定 相应 的 附加 的 规 
程 ,每 一 种 选择 都 应 与 GB 9386 相 吻 合 。 当 测试 用 例 和 测试 规程 的 对 应 关系 不 是 很 明显 时 ,用 表格 连接 
它们 ,并 将 其 放 于 单元 测试 设计 说 明 中 。 

e. ”获得 测试 用 例 说 明 

指定 新 的 测试 用 例 , 可 参考 现存 的 测试 用 例 说 明 。 

将 该 测试 用 例 直接 记录 于 或 通过 引用 的 方式 记录 于 单元 的 测试 设计 说 明 的 补充 章 条 中 或 男 外 的 文 
件 中 。 记 录 的 文件 必须 符合 GB 9386 的 要 求 ,并 放 于 单元 的 测试 设计 说 明 中 。 

d. ”根据 设计 信息 , 按 需 要 扩大 测试 用 例 集 的 说 明 

根据 单元 设计 的 信息 , 按 需 要 更 新 测试 集 层 次 结构 ,注意 应 与 4.4.1 条 的 a 保持 一 致 ,并 考虑 所 选 
算法 及 内 部 数据 结构 等 软件 特征 。 

如 果 要 确定 控制 流程 及 确定 必须 记录 的 内 部 数据 的 变化 情况 , 则 应 考虑 到 可 能 产生 的 特殊 记录 的 
困难 。 例 如 ,跟踪 复杂 算法 中 的 控制 流 或 跟踪 内 部 数据 结构 (如 栈 或 树 ) 的 变化 时 存在 的 记录 困难 。 若 需 
求 的话 , 应 增强 单元 设计 (例如 格式 化 数据 结构 、 转 储 功 能 ) 以 增强 单元 的 可 测试 性 。 

根据 单元 设计 中 的 信息 ,描述 那些 新 增加 的 测试 用 例 , 并 完成 各 部 分 的 测试 用 例 说 明 , 同 时 应 与 
4.4.2 条 的 c 保持 一致 。 

e. ”完成 测试 设计 说 明 

完成 被 测 单 元 的 测试 设计 说 明 , 并 与 GB 9386 相 一 致 。 
4.4.5 输出 

a. ”单元 测试 设计 说 明 ( 从 4.4.2 条 的 e 得 到 )，; 

b. ”附加 的 测试 规程 说 明 ( 若 能 从 4.4.2 条 的 b 得 到 )，; 

e- ”附加 的 测试 用 例 说 明 ( 若 能 从 4.4.2 条 的 c~d 得 到 )， 

d. ”单元 设计 的 增强 需求 ( 若 能 从 4.4.2 条 的 d 得 到 )。 
4.5 执行 计划 及 实现 设计 
4.5.1 输入 

a. 单元 测试 计划 (从 4.1.2 条 的 aee 及 4.3.2 条 的 a~c 得 到 )，; 

b. 在 单元 测试 设计 说 明 或 附加 文件 中 的 测试 用 例 说 明 ( 从 4.4.2 条 的 cd 得 到 ); 

c. 软件 数据 结构 描述 ; 
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d. ”测试 支持 资源 ; 

e. 测试 项 ; 

fi. 来 自 以 前 测试 活动 的 测试 数据 ( 若 存 在 7 

g- 来 自 以 前 测试 活动 的 测试 工具 ( 若 存 在 ) 。 
4. 5.2 任务 

a. 获得 并 验证 测试 数据 

对 于 能 稍 作 修改 或 不 作 修 改 便 可 使 用 的 测试 数据 ,获得 它们 的 一 份 备 份 , 按 需 求 产生 新 的 数据 。 为 
保证 数据 的 一 致 性 和 完整 性 ,还 应 包含 附加 数据 。 按照 软件 数据 结构 规格 说 明 验 证 所 有 数据 。 当 测试 用 
例 和 数据 集 的 关系 不 明显 时 ,用 表格 来 记录 此 种 关系 ,并 放 于 单元 测试 设计 说 明 中 。 

b. 获得 指定 资源 

获得 4.3.2 条 的 b 中 指定 的 测试 文 持 资源 。 

c. 获得 测试 项 

收集 包含 已 有 的 手册 .操作 系 统 规程 .控制 数据 (如 表格 ) 和 计算 机 程序 在 内 的 所 有 测试 项 ,获得 在 
测试 设计 期 间 确 定 的 与 测试 单元 有 直接 接口 的 软件 。 
当 测 试 一 个 用 过 程 性 语言 实现 的 单元 时 ,要 保证 执行 轨迹 信息 足以 能 够 满足 基于 代码 的 程序 的 完 
备 性 要 求 。 

将 每 一 项 的 标识 符 记 录 于 单元 测试 总 结 报告 的 “ 简 述 ”一 章 中 ( 见 GB 9386) 。 
4.5.5 输出 

a. 验证 过 的 测试 数据 (从 4.5.2 条 的 a 得 到 )， 

b. 测试 支持 资源 (从 4.5.2 条 的 b 得 到 )，; 

e. 测试 项 的 配置 (从 4.5.2 条 的 c 得 到 ); 

d. ”初步 总 结 ( 从 4.5.2 条 的 c 得 到 )。 
4.6 执行 测试 规程 
4.6.1 输入 









































































































































































































































a- ”验证 过 的 测试 数据 (从 4.5.2 条 的 a 得 到 7 
b. ”测试 支持 资源 (从 4.5.2 条 的 b 得 到 ); 
e- 测试 项 的 配置 (从 4.5.2 条 的 e 得 到 75 
d. 测试 用 例 说明 ( 从 4.4.2 条 的 c,d 得 到 )， 
e. 测试 规程 说 明 ( 若 4.4.2 条 的 b 能 够 产生 ); 
f.。 故障 分 析 结 果 ( 从 排 错过 程 得 到 ) 。 

4.6.2 任务 
图 3 为 执行 测试 规程 活动 内 的 控制 流程 图 。 




















a. 运行 测试 
建立 测试 环境 ,运行 测试 集 。 在 单元 测试 总 结 报告 的 “结果 概述 ”一 章 中 记录 所 有 的 软件 测试 事件 。 
b. ”判定 结果 
对 每 一 个 测试 用 例 , 利 用 测试 用 例 描 述 文件 中 有 关 的 所 需 结果 的 规格 说 明 , 来 判定 单元 测试 活动 是 
通过 还 是 失效 。 将 通过 或 失效 结果 记录 于 单元 测试 总 结 报 告 的 “结果 概述 ”一 章 中 。 将 资源 消耗 数据 记 
录 于 报告 的 “活动 总 结 ” 一 章 中 ( 见 GB 9386) 。 当 测试 一 个 用 过 程 性 语言 实现 的 单元 时 ,收集 执行 轨迹 的 
总 结 信 息 , 且 将 其 添 入 总 结 报告 中 。 
对 每 一 次 失效 ,应 加 以 分 析 并 将 出 错 信息 记录 在 测试 总 结 报告 的 结果 概述 ”一 章 中 ,然后 选择 以 下 
适用 情况 执行 相应 措施 。 
情况 1 ;测试 规格 说 明 或 测试 数据 的 故障 
改正 错误 ,将 改正 错误 信息 记录 在 测试 总 结 报告 的 “活动 总 结 ” 一 章 中 ,然后 重新 运行 该 测试 。 

















































































































































































































































































































GB/T 15532 一 1995 





情况 2: 执 行 测试 规程 时 的 故障 
重新 运行 未 正确 执行 的 规程 。 
情况 3: 测 试 环境 (例如 系统 软件 ) 中 的 故障 
将 环境 修正 ,将 环境 修正 情况 记录 在 测试 总 结 报 告 的 “活动 总 结 ” 一 革 中 ,然后 重新 运行 该 测试 ;或 
者 预先 设置 异常 终止 情况 ,将 不 能 修正 环境 的 理由 记录 于 测试 总 结 报告 的 “活动 总 结 ” 一 章 中 ,然后 开始 
核对 终止 情况 ( 即 开始 执行 4.7 条 的 活动 )。 
情况 4; 单 元 实现 故障 

修正 错误 ,并 将 修正 错误 情况 记录 在 测试 总 结 报告 的 “活动 总 结 ” 一 章 中 ,然后 重新 运行 所 有 的 测 
试 ; 或 者 预先 准备 异常 终止 情况 ,将 不 能 进行 单元 修正 的 理由 记录 于 测试 总 结 报告 的 “活动 总 结 ” 一 章 
中 ,然后 开始 核对 终止 情况 ( 即 开始 执行 4.7 条 的 活动 )。 
情况 5: 单 元 设计 故障 
医 正 单元 设计 并 实现 ,在 适当 的 时 候 修 改 测试 规格 说 明 及 数据 ,将 错误 修正 情况 记录 于 测试 总 结 报 
告 的 “活动 总 结 ” 一 章 中 ,然后 重新 运行 所 有 的 测试 ,或 者 ,预先 设置 异常 终止 情况 ,将 不 能 进行 设计 修正 
的 理由 记录 于 测试 总 结 报告 的 “活动 总 结 ” 一 章 中 ,然后 开始 核对 终止 情况 ( 即 开始 执行 4.7 条 的 活动 )。 
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测试 错误 软件 销 误 
十 
否 
络 正 情况 的 核对 








图 3 执行 测试 规程 活动 内 的 控制 流程 





4.6.5 输出 
a. ”包含 在 测试 总 结 报告 中 的 执行 信息 ,其 中 包括 测试 输出 ,软件 测试 事件 描述 ,故障 分 析 结 果 、 错 
误 修 正 活动 \ 不 能 修改 错误 的 理由 ,资源 消耗 数据 ;对 过 程 性 语言 实现 的 程序 而 言 ,还 应 包括 执行 轨迹 总 
结 信息 (从 4.6.2 条 的 ab 产生 ); 
b. 修订 后 的 测试 规格 说 明 ( 若 能 从 4.6.2 条 的 b 得 到 )， 
c. 修订 后 的 测试 数据 ( 若 能 从 4.6.2 条 的 b 得 到 )。 
4.7 核对 终止 情况 
4.7.1 输入 
a. ”完备 性 和 终止 情况 的 需求 说 明 ( 从 4.1.2 条 的 be 得 到 )， 
b. 执行 信息 (从 4.6.2 条 的 ab 得 到 ); 
c. 测试 规格 说 明 ( 从 4.4.2 条 的 a~c 得 到 )( 若 有 需要 ); 
d. ”软件 数据 结构 描述 (车 有 需要 )。 
4.7.2 任务 
图 4 为 结果 核对 活动 内 的 控制 流程 图 。 
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a. 对 测试 过 程 的 正常 终止 情况 进行 核对 





人 执行 测试 规程 


补充 测试 集 








评价 测试 效果 
及 单元 














图 4 结果 核对 活动 内 的 控制 流程 









































根据 完备 性 要 求 或 失效 记录 ,决定 是 否 要 增加 新 的 测试 。 对 于 用 过 程 性 语言 实现 的 程序 ,要 分 析 执 
行 轨迹 总 结 信息 (例如 变量 、 数 据 流 )。 


若 不 需 附 加 测试 , 则 将 正常 终止 情况 记录 于 测试 总 结 报告 的 “活动 总 结 ” 一 章 
F 始 执行 4.8 条 的 活动 )。 

过 程 的 异常 终止 情况 进行 核对 

后 (《 例 如 重要 错误 不 能 修正 、 超 时 ), 则 应 将 导致 终止 的 特殊 条 件 记录 于 测试 总 结 





效果 及 被 测 单 元 ( 即 必 
b. 对 测试 
若 满 足 异 常 终止 条 
报告 的 “活动 总 结 ” 一 章 
测 单元 ( 即 
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当前 安 




















































































































!, 然 后 开始 评价 测试 























! 同时 也 应 记录 未 完成 的 测试 及 未 被 修正 的 错误 ,然后 





开始 执行 4.8 条 的 活动 )。 
补充 测试 集 
附加 的 测试 且 异 常 终 上 上 情况 不 满足 时 ,通过 下 列 步骤 来 补充 测试 集 。 
新 测试 集 的 结构 ,并 与 4.4.2 条 的 a 一致, 且 根据 4.4.2 条 的 c 获得 相应 的 测试 用 例 说 明 ， 



































一 一 按 需 要 根据 4.4.2 条 的 b, 修 改 测试 规程 说 明 ; 
一 一 根据 4. 5.2 条 的 a 获 得 附加 测试 数据 ; 


一 一 将 附加 内 容 记 录 于 测试 总 结 报告 的 “活动 总 结 ” 一 草 中 





























一 一 执行 附加 的 测试 ( 即 返回 4.6 条 的 活动 ) 。 
4.7.5 输出 
a- ”记录 于 测试 总 结 报告 内 的 核对 信息 ,包括 终止 条 件 及 任何 测试 用 例 的 附加 情况 (从 4.7.2 条 的 


a~c 得 到 ); 


b. 


























附加 的 或 修订 后 的 测试 规格 说 明 ( 若 能 从 4.7.2 条 的 c 得 到 ); 


ce. 附加 的 测试 数据 ( 若 能 从 4.7.2 条 的 c 得 到 )。 
4.8 评价 测试 效果 和 被 测 单元 
4.8.1 输入 
a. ”单元 的 测试 设计 说 明 ( 从 4.4.2 条 的 e 得 到 ); 
b. 执行 信息 (从 4.6.2 条 的 ab 得 到 )， 












































ce. 核对 
d. ”附加 的 测试 用 
4. 8.2 任务 
a. ”描述 测试 状态 
将 测 i 
明 每 次 变化 的 原因 。 

















言 息 ( 从 4.7.2 条 的 a~c 得 到 )，; 





例 说 明 ( 若 能 从 4.4.2 条 的 cd 得 到 )。 






































F 价 测试 效果 及 被 





A > 
BD 





式 计划 和 测试 规格 说 明 的 变化 情况 记录 于 测试 总 结 报告 的 “差异 ”一 章 中 ( 见 GB 9386)。 要 说 





对 异常 终止 情况 ,要 确定 未 能 被 测试 活动 充分 地 覆盖 的 区 域 , 且 将 理由 记录 于 测试 总 结 报告 的 “ 测 
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试 充分 性 评价 ”一 章 内 ( 见 GB 9386) 。 
确定 未 能 解决 的 软件 测试 事件 以 及 不 能 解决 的 理由 ,并 记录 于 测试 总 结 报告 的 “结果 概述 ”一 章 中 
b. 描述 单元 状态 
将 通过 测试 所 反映 的 单元 与 其 需求 文件 之 间 的 差异 记录 于 测试 总 结 报告 的 “差异 ”一 章 
将 测试 结果 及 所 发 现 的 错误 情况 同 需 求 对 照 ,评价 单元 的 设计 与 实现 ,将 评价 信息 记录 于 测试 总 结 
报告 的 “测试 充分 性 评价 ”一 章 中 。 
c. 完成 测试 总 结 报告 
根据 GB 9386, 完 成 测试 总 结 报告 。 
d. ”保存 测试 文件 
确保 测试 得 到 的 成 果 的 收集 ,组织 和 存储 ,以 备 调用 及 重用 。 这 些 成 果 包 括 测 试 设计 说 明 、 附 加 的 测 
试用 例 说 明 、 附 加 的 测试 规程 说 明 、 测 试 数据、 测试 用 例 的 产生 规程 ,测试 驱动 程序 和 桩 模块 以 及 测试 总 
结 报 告 。 
4.8.5 输出 

a. ”测试 总 结 报告 (从 4.8.2 条 的 c 得到); 

b- 测试 成 果 的 收集 存储 (从 4.8.2 条 的 d 得 到 )。 
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附 录 A 
实现 及 使 用 指南 
(参考 件 ) 





























本 附录 包含 使 用 本 标准 时 有 益 的 信息 。 因 此 建议 在 作出 更 为 详细 的 计划 之 前 先 阅读 本 附录 。 
A1 标准 的 使 用 

本 标准 有 以 下 作用 ， 

a. 作为 为 确定 当前 的 实践 活动 而 比较 的 基础 ; 

b. 作为 修改 当前 实践 活动 的 思路 之 源 ; 

c. 作为 当前 实践 活动 的 奉 代 物 。 
A2 ”附加 的 测试 需求 

对 每 个 项 目 , 象 附加 测试 文件 (如 测试 日 志 ) 的 数量 ,应 当 描述 的 细致 程度 及 批准 ,复查 的 数量 和 类 


型 等 等 这 样 的 需求 都 应 详细 说 明 。 有 些 因素 ,如 单元 的 批评 意见 ,读者 需求 或 合同 说 明 会 经 常 影 响 这 些 
需求 ,本 标准 将 这 种 需求 留 给 用 户 自 己 去 描述 ,该 描述 可 作为 单独 项 目的 需求 ,认可 作为 茶 个 组 织 的 标 
准 。 若 这 些 需 求 是 某 个 项 目 特 指 的 , 则 应 在 项 目 计划 \、 质 量 保证 计划 .证 明 及 验证 计划 或 全 局 的 测试 计划 
中 进行 描述 。 
Ag5 附加 的 测试 文件 

一 般 认为 测试 设计 说 明和 测试 总 结 报告 中 包含 的 信息 是 完成 测试 过 程 后 得 到 的 最 小 文件 集合 。 男 
外 ,通过 在 这 些 文件 中 增加 附加 内 容 或 增加 额外 的 文件 ,GB 9386 中 描述 的 测试 文件 集 可 以 满足 所 要 求 
的 任何 测试 信息 。 


A4 认可 及 评审 


如 要 求 更 多 的 控制 ,应 考虑 以 下 附加 任务 ， 
在 计划 阶段 的 末尾 认可 总 的 方法 ; 
在 确定 测试 特性 阶段 的 末尾 认可 所 确定 的 需求 ; 
在 细 化 计划 阶段 的 末尾 认可 所 描述 的 计划 ， 
在 设计 测试 集 的 末尾 认可 测试 说 明 ; 
在 实现 测试 阶段 的 末尾 认可 测试 准备 情况 ; 
在 评估 阶段 认可 测试 总 结 报告 。 
A5 审计 
当 描 述 控制 需求 时 有 必要 考虑 审计 问题 。 因 此 ,应 当 从 测试 评审 中 产生 足够 的 测试 文件 及 报告 ,以 
满足 所 要 求 的 所 有 审计 信息 。 
A6 配置 管理 

配置 管理 以 软件 需求 、 软 件 结构 设计 、 软 件数 据 结构 及 单元 需求 文件 作为 输入 源 。 必 须 合 理 地 管理 
这 些 输入 文件 ,以 便 确 保 我 们 持 有 的 是 现行 的 信息 ,并 且 任 何 变动 都 能 得 到 通知 。 

单元 测试 的 最 终 文 件 也 应 进行 配置 管理 。 必 须 管 理 好 这 些 输出 文件 以 便 进 行 全 面 而 经 济 的 测试 。 详 
见 GB/T 12505。 
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A7 确定 基于 需求 的 特性 
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对 单元 开发 人 员 而 言 , 当 在 测试 中 确定 基于 需求 的 元 素 ( 如 特性 、 规 程 、 状 态 转 换 、 数 据 特征 ) 的 有 效 






















































































当 

















集合 时 ,心理 因素 (如 
由 其 他 人 来 完成 。 

















自信 心 、 关 于 单元 设计 的 详细 知识 ) 起 了 阻碍 作用 。 通 常 ,这 样 的 “确定 特性 ”过 程 应 

















有 以 下 几 种 方式 完成 这 种 活动 ， 


a. 开发 人 员 之 间 相 互 丰 
b. 开发 人 员 之 间 完 整 


的 详细 知识 ; 














上 定 这 些 特性 ; 

















测试 他 人 的 代码 ,这 和 带 来 的 优点 是 至 少 两 名 开发 人 员 将 会 熟悉 每 个 单元 


ce. 组 织 一 个 独立 的 测试 小 组 。 项 目的 大 小 或 软件 的 重要 性 可 以 决定 是 否 适 合 组 织 这 样 的 独立 的 


测试 小 组 。 



































若 开发 人 员 为 自己 的 软件 确定 基于 需求 的 元 素 , 他 们 应 当 在 软件 设计 开发 之 前 完成 这 种 确定 工作 。 





A8 用 户 的 参与 


若 在 测试 茶 一 单元 


对 需 与 用 户 交互 进行 (如 菜单 显示 ), 则 应 请 用 户 参 与 确定 基于 需求 的 元 素 的 工 














作 , 这 样 效果 会 更 好 。t 





作 测试 计划 时 向 用 户 询问 其 使 用 情况 会 发 现 非常 有 价值 的 信息 。 例 如 ,通过 询 























问 可 能 明确 相对 习 
A9 更 强 的 代码 覆盖 需求 
































针对 单元 的 
强 4.1.2 条 的 b 中 






































































































































# 元 功能 ,从 而 确定 出 测试 的 重点 。 





EE 要 性 或 单元 需求 说 明 与 设计 信息 的 不 足 ( 如 在 维护 旧 的 软件 时 发 生 的 情况 ), 可 以 加 


















































E 于 代码 的 履 盖 需求 。 其 中 一 种 方式 便 是 将 指令 履 盖 的 要 求 增强 到 分 文 禾 盖 























的 要 求 ( 即 要 求 凯 历 单元 中 每 一 个 分 支 )。 


A10 代码 覆盖 工具 




















这 里 大 力 推荐 一 种 在 测试 单元 执行 时 记录 源 代 码 政 盖 量 的 自动 化 方式 。 之 所 以 使 用 自动 化 方式 就 
是 因为 手工 覆盖 分 析 不 可 靠 且 不 经 济 。 使 用 代码 控 测 及 报告 工具 就 是 一 种 自动 化 方式 的 工具 ,该 工具 将 

















软件 探测 器 放置 于 源 代码 





































































































!, 以 后 在 运行 测试 用 例 时 便 可 提供 一 份 总 结 了 数据 及 控制 流 信息 的 报告 。 该 




















报告 会 指出 未 运行 过 的 指令 。 有 些 工具 还 能 指出 未 运行 的 分 支 。 有 些 编译 器 也 具备 这 种 特点 。 


A11 测试 过 程 的 补充 














为 了 评价 并 增强 单元 测试 的 有 效 性 ,建议 在 单元 测试 之 后 的 步骤 如 组 装 测试 ,系统 测试 ,产品 使 用 











A 




















实现 一 个 新 技术 的 过 程 ,其 本 喘 就 是 一 个 需要 计划 、 实 现 及 评价 效果 的 过 程 。 为 了 成 功 地 实现 基 ] 









































和 活动 中 收集 失效 数据 。 然 后 分 析 这 些 数据 以 便 确定 那些 本 应 被 单元 测试 检查 出 却 未 被 查 出 的 错误 。 
A12 本 标准 的 使 用 






























































本 标准 的 测试 ,测试 人 员 必须 开发 一 份 实现 策略 并 将 本 标准 作 适 当 裁 剪 。 这 两 个 活动 必须 反映 出 组 织 
部 的 文化 背景 及 权威 性 。 若 要 成 功 地 完成 一 个 长 期 项 目 , 还 需要 专门 的 管理 以 及 支持 的 政策 .工具 .培训 





和 起 动 协议 。 





A15 标准 的 可 实施 性 
本 标准 同 许多 好 的 软 伯 








涉及 到 新 的 政策 及 规程 ,六 
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F 工 程 实践 有 一 致 的 定义 。 某 些 组 织 采 用 与 此 相似 的 实践 活动 而 男 外 一 些 却 
完全 不 同 。 无论 如 何 , 对 许多 决定 选择 本 标准 并 适应 本 标准 的 组 织 而 言 , 它 都 会 有 某 种 变化 。 这 种 变化 
的 工具 以 及 新 的 培训 程序 。 若 标准 与 实际 相差 太 大 , 则 有 必要 对 标准 进行 某 





















































































































































种 改变 。 解 决 实 月 
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性 问题 的 答案 从 根本 上 





















































































































































(参考 件 ) 









































































































































































































































B1 软件 工程 概念 

本 标准 中 描述 的 标准 化 单元 测试 过 程 是 建立 在 软件 工程 一 些 基 本 概念 之 上 的 ,Bl. 1 一 B1.8 条 描述 
了 这 些 概念 。 
B1.1 测试 与 验证 、 确 认 的 关系 

测试 只 是 一 系列 包含 验证 ,确认 等 活动 中 的 一 个 。 其 他 活动 有 技术 评审 (如 代码 审查 ) ,静态 分 析 及 
正确 性 证 明 。 综 合 性 验证 及 确认 过 程 的 规范 不 属于 本 标准 的 范围 。 
B1.2 像 产 品 开发 般 的 测试 

测试 是 一 个 开发 产品 的 过 程 ,其 结果 是 产生 一 个 测试 集 ,包括 使 用 的 数据 ,测试 文 持 软件 及 规程 ,该 
产品 以 文件 形式 记录 于 测试 规范 说 明 及 报告 中 。 同 其 他 产品 开发 过 程 一 样 ,开发 测试 集 要 求 有 计划 、 需 
求 (测试 目标 )、 设 计 、 实 现 以 及 评价 等 阶段 。 
B1.5 排 错过 程 的 组 成 

排 错过 程 由 两 个 主要 的 活动 组 成 。 第 一 步 活动 即 失效 分 析 的 目标 是 确定 导致 一 次 失效 的 所 有 错误 
的 地 点 。 第 二 步 活动 即 改正 错误 的 目标 是 去 除 所 有 查 出 的 错误 并 避免 产生 新 的 错误 。 关 于 失效 分 析 及 
背 误 改正 的 过 程 的 规范 说 明 不 属于 本 标准 的 范围 。 
B1.4 测试 与 排 错 的 关系 

测试 是 为 了 检查 错误 而 力图 引出 失效 ,而 排 错 既 要 进行 失效 分 析 并 判定 有 关 错 误 的 地 址 ,又 要 改正 

































































错误 。 测 试 可 能 需要 来 自 排 错过 程 的 失效 分 析 的 结果 来 决定 终止 测试 ,请求 改变 需求 或 进行 错误 改正 等 


这 相 


B1- 


实现 单元 (如 一 段 程 
B1.6 对 设计 与 实践 信息 的 需求 

一 般 来 讲 , 尽 管 测试 的 本 质 是 将 实际 执行 情况 与 所 需 》 
已 足以 帮助 进行 有 效 的 测试 。 这 是 





的 活动 。 














5 单元 类 型 之 间 的 关系 


























没有 必要 在 设计 单元 ,实现 单元 与 测试 单元 之 间 建 立 一 一 对 应 的 关系 。 儿 个 设计 单元 可 能 组 成 一 个 


























情况 提供 足够 的 指南 。 


设计 和 实现 信息 。 
B1.7 测试 


元 的 信息 。 甚 结果 是 ,测试 所 考虑 的 元 素 可 
程 语言 的 实现 而 言 ( 
动 阶段 有 基于 单元 需求 文件 ; 


述 阶段 所 描述 的 上 








序 ), 而 儿 个 实现 单元 可 能 组 成 一 个 测试 单元 。 
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本 颖 


制 




















单元 需求 文人 





中 所 考虑 的 元 素 说 明 的 补充 
F、 单 元 设计 文件 以 及 在 最 后 单元 实现 过 程 























能 会 在 不 同 的 测试 活动 























对 过 程 | 





生 纺 


三 
[一 














有 定 



























































代 但 o 


一 次 是 在 确定 特性 活动 阶段 ,基于 需求 说 明 ;第 二 次 是 


书 。 











情况 进行 对 照 衡量 ,但 并 不 能 认为 需求 信息 
于 通常 不 可 能 测试 所 有 可 能 的 情况 , 而 需求 说 明 并 不 对 失效 率 高 的 











于 这 些 失 效率 高 的 情况 是 设计 和 实现 选择 时 造成 的 结果 ,所 以 测试 时 通常 需要 








中 ,会 渐渐 发 现 更 详细 的 关于 测试 单 
期 间 得 到 补充 。 
1COBOL ) ,元 素 说 明 出 现 三 次 补充 。 第 一 组 是 在 确定 特性 这 一 活 
第 二 组 是 在 设计 测试 集 这 一 活动 阶段 确定 的 , 它 基 于 软件 设计 



































元 设计 信息 ( 即 算 法 与 数据 结构 ); 第 三 组 是 在 核对 结果 这 








对 非 过 程 性 编 





程 语言 的 实现 而 言 ( 如 报告 4 
































阶段 有 








定 的 , 它 基 于 单元 








E 成 器 或 分 类 的 规格 化 语言 ,元素 说 明 出 现 两 次 补充 。 第 
全 设计 测试 集 活动 阶段 ,基于 非 过 程 的 规格 说 明 
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有 一 和 和 


代码 的 放 

















补充 方法 , 它 允 v 
LE 细 知 识 之 间 的 差别 。 














B1.8 对 创建 测试 设计 说 明 的 补充 
测试 设计 说 明 中 记录 的 信息 是 如 
阶段 的 进行 ,有 


成 。 


B1.9 对 创建 测试 总 结 报 告 的 补充 
测试 总 结 报告 中 记录 的 信息 是 寿 
在 执行 及 核对 阶段 修改 ,在 记 
B2 测试 假设 
本 标准 中 
给 出 这 种 假设 上 
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F 在 获得 需求 文件 乙 时 便 开 始 单元 测试 ,并 最 大 限度 地 减少 单元 设计 与 单元 





定 特性 ` 细 化 计划 和 设计 测试 集 阶段 收集 的 。 随 着 每 个 测试 活 亏 
关 说 明 的 相应 章 条 记录 了 信息 。 所 有 的 文件 必须 在 设计 测试 集 活动 的 最 后 重复 的 末尾 完 





FE 测试 计划 阶段 之 外 所 有 测试 活动 阶段 得 到 的 ,在 实现 测试 时 初 建 ， 
































9 方法 是 建立 在 有 关 经 济 、 心 理 






























































B2.1 自 











Aa. 


b 
© 
d. 
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B2.2 洲 




















、 技 术 等 几 利 
































假设 之 上 的 。B2. 1~B2.7 条 














# 元 测试 的 目标 之 一 就 是 判断 根据 单元 需求 及 设计 文件 而 实现 的 单元 的 正确 性 与 完备 性 。 它 试 
图 在 以 下 几 项 中 发 现 错误 ， 


























单元 需求 特性 ,并 结合 其 相应 的 
关于 无 效 输 入 的 单元 手册 ; 
仅 与 单元 相关 的 任何 使 用 及 操作 规程 
# 元 的 算法 或 内 部 数据 结构 ,或 两 者 都 有 ; 
单元 控制 逻辑 的 判定 边界 。 

I 试 的 内 容 之 一 是 根据 需求 核对 实际 情况 。 人 们 总 是 非 正 式 地 说 起 接口 测试 ,语句 测试 或 需求 









































em 
























































述 ( 如 不 活动 活动 等 待 一 个 信和 号、 





舌 动 处 理 一 个 信号 )4 








说 明 测试 ,其 意义 束 是 对 照相 应 的 接口 、 语 句 、 需 求 说 明 的 描述 来 核对 它们 的 实际 情况 ,任何 可 核对 的 单 


在 。 























元 测试 过 程 都 必须 有 该 





元 的 需求 说 明文 从 

















B2.3 单元 需求 说 明文 
评审 过 ,不 论 是 作为 评审 过 程 的 


























EF 必须 经 过 完备 性 、 可 测试 性 及 可 跟踪 性 的 全 面 记 
个 部 分 ,还 是 以 特殊 的 单 











F。 本 标准 假设 在 测试 开始 之 前 该 单元 测试 需求 文件 已 经 存 











审 。 本 标准 假设 需求 说 明 已 
元 需求 说 明 进行 的 评审 。 











B2.4 在 查 错 的 早 基 


























要 的 经 济 效益 。 这 意味 者 














Wy 当 在 一 获得 




















之 时 便 用 
的 测试 。 


























B2.7 木 标准 认为 拖延 测试 用 
及 设计 的 特点 ,这 种 影响 直到 测试 集 执行 之 后 才 结 束 。 这 村 
于 代码 的 设计 在 获得 测试 执行 数据 之 前 便 已 开始 , 贝 
说 明之 后 再 开始 。 
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F 始 开发 测试 集 , 这 是 日 





啊 需 求 的 验证 及 

















B2.5 项 





目测 试 的 级 别 ( 如 验收 、 系 统 、 旨 





























单元 需求 说 明文 件 并 进行 测试 

















认 。 这 也 意味 着 如 





单元 一 级 应 进行 尽 可 能 








昌 装 单元) 是 在 项 目 计划 、 验 收 及 胡 














i 述 的 。 同 时 这 些 计划 









































要 约束 。 振 能 获 和 








必要 的 资源 , 某 些 活动 及 一 个 活动 内 的 某 些 





于 所 有 被 测试 单元 的 单元 测试 计划 
求 、 资 源 总 需求 )。 继 而 ,根据 对 软件 设计 的 分 析 , 标识 出 测试 身 
B2.6 完成 一 个 任务 所 需 





















































认 计 划 或 全 局 测试 计划 中 














这 息 (如 完备 性 需求 ,终止 需 
元 ,选择 组 装 序列 。 
9 可 获得 性 是 决定 活动 顺序 和 活动 内 的 任务 顺序 的 主 




















任务 便 可 


































































































以 并 行 执 行 。 











F 销 的 最 大 因素 ,此 处 测试 集 是 基于 源 代码 特点 和 需求 
的 方法 使 基于 代码 的 设计 任务 最 小 化 。 若 基 
j 它 应 在 那些 基于 需求 及 设计 特点 的 测试 用 例 已 被 
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附加 说 明 ， 
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本 标准 








上 海 计算 机 软件 技术 开发 中 心 负责 起 草 。 











本 标准 了 





要 起 草 人 朱 三 元 \ 刘 光 龙 、. 汉 惠 \ 周 庆 隆 、 和 为 民 、 陈 长 分。 


